Reading data from the magnetic stripes on credit and debit cards has primarily been performed by swiping the magnetic stripe against reader heads of a magnetic stripe reader (MSR). The data contained in the magnetic stripe is encoded in discrete tracks (channels) whose content and/or format are different. The movement of the card causes the magnetic fields produced by magnetic domains contained in the stripe to induce voltages in the MSR's read heads. A magnetic domain is a region within a magnetic material in which magnetization is in a uniform direction. In the track of a magnetic stripe card, each domain is magnetized in a direction that is parallel to the length of the magnetic stripe.
An MSR is capable of reading the data from one or more tracks/channels, and includes a read head for each channel that will be read. The MSR reads the data encoded in a track by converting a sequence of voltages induced in a channel's read head into a series of binary bits. The tracks are spaced close to each other, so each read head is precisely lined up with a corresponding track of the magnetic stripe.
The tracks of a typical magnetic stripe card 100 are described with reference to FIG. 1. As illustrated, there are three tracks of data (labeled as 101, 102, and 103), which are encoded in the magnetic stripe 11. On a standard credit/debit card, the magnetic stripe is located 0.223 inches (5.66 mm) from the edge of the card. A width 111 of each of the three tracks is 0.110 inches (2.79 mm). Each track conforms to a different encoding standard 112. The standard 112 corresponding to a track specifies the respective track's recording density 113 and character configuration 114 (in terms of bits-per-character and character type). Each track may contain a different number of characters (Information Content 115), with the maximum number of characters in each track specified in the corresponding standard 112.
The format of Track 1 101 was specified in a standard 112a developed by the International Air Transaction Association (IATA) for the automation of airline ticketing or other transactions where a reservation database is accessed. Track 1 101 typically has a recording density 113a of 210 bits per inch (8.27 bits per mm). The character configuration 114a of Track 1 101 is 7-bit alphanumeric characters. The information content 115a (including control characters) is limited to a maximum of 79 characters.
The format of Track 2 102 was specified in a standard 112b developed by the American Bankers Association (ABA) for the automation of financial transactions. Track 2 information is also used by most systems that require an identification number and other control information. Track 2 102 typically has a recording density 113b of 75 bits per inch (2.95 bits per mm). The character configuration 114b of Track 2 102 is 5-bit numeric characters (plus 5-bit control characters). The information content 115b (including control characters) is limited to a maximum of 40 characters.
The format of Track 3 103 is specified by a standard 112c developed by the Thrift-Savings industry. Track 3 103 typically has a recording density 113c of 210 bits per inch (8.27 bits per mm). The character configuration 114c of Track 3 103 is 5-bit numeric characters (plus 5-bit control characters). The information content 115c (including control characters) is limited to a maximum of 107 characters. Track 3 103 is unused by many of the major worldwide financial networks, and sometimes is not even physically present on a card, allowing for a narrower magnetic stripe. However, Track 3 103 is used in certain places, such as China, typically as an alternative to Track 2 102.
FIG. 2 illustrates an example data structure stored on Track 1 101 of a payment card. Track 101 may include the following data fields (in this order):
SS|FC|PAN|FS|Name|FS|Additional Data|Discretionary Data|ES|LRC.
The data structure of Track 1 comprises a one-character Start Sentinel (SS) 210 and a one-character End Sentinel 226, with up to 76 data characters (211) in-between. The Start Sentinel (SS) 210 and the End Sentinel 226 are “control” characters specified by the track standard 112a. The data characters 211 may also include control characters, such as characters that delimit between fields. An example of a control character included within the data sequence 211 is a Field Separator 216.
The one-character Start Sentinel (SS) 210 indicates the beginning of the data structure and consists of a “%” (percent sign) character. A one-character Format Code (FC) 212 is an alphabetic-only (A-to-Z) character and indicates the card type. A Primary Account Number (PAN) field 214 comprises the credit/debit card number, is always numerical, and contains up to 19 digits. The one-character Field Separators (FS) 216a and 216b delimit different fields and each consists of a “{circumflex over ( )}” (caret) character. A Name field 218 corresponds to the name of a particular card account holder, and consists of two-to-twenty-six character alphanumeric characters. A surname separator consisting of a “/” (forward slash) character may be used to separate the card account holder's surname from their first name. If the Name field 218 is not used, it may be replaced with one upper case letter or a null (such as a blank-space character or zero) followed by a “/” (forward slash) character.
An Additional Data field 222 typically includes up to seven numbers. Four of the numbers may indicate an expiration date of the card in a YYMM format. If the date field information is not included, another field separator 216 may be included instead. Three of the numbers of the Additional Data field 222 may be a three-character service code relating to the types of charges that may be accepted. If the service code field is omitted, another field separator 216 may be included instead.
A Discretionary Data field 224 includes data used for card verification information. Examples of the discretionary data include a one-character PIN Verification Key Indicator (PVKI), a four-character PIN Verification Value (PVV) or Offset, and a three-character Card Verification Value (CVV) or Card Validation Code (CVC). The one-character End Sentinel (ES) 226 indicates an end of the data structure and consists of a “?” (question mark) character. A one-character Longitude Redundancy Check (LRC) 228 is included at the end of the data structure to provide verification that Track 1 101 was accurately read by the MSR.
FIG. 3 illustrates an example data structure stored on Track 2 102. Track 2 102 may include the following data fields (in this order):
SS|PAN|FS|Additional Data|Discretionary Data|ES|LRC.
The data structure of Track 2 comprises a one-character Start Sentinel (SS) 310 and a one-character End Sentinel 326, with up to 37 data characters (311) in-between. The Start Sentinel (SS) 310 and the End Sentinel 326 are “control” characters specified by the track standard 112b. The data characters 311 may also include control characters, such as characters that delimit between fields. An example of a control character included within the data sequence 311 is a Field Separator 316.
The one-character Start Sentinel (SS) 310 indicates the beginning of the data structure and consists of a “;” (semicolon) character. A Primary Account Number (PAN) field 314 is similar to the PAN 214 in Track 1. The PAN field 314 comprises the credit/debit card number, is always numerical, and contains up to 19 digits. The one-character Field Separator (FS) 316 consists of a “=” (equals sign) character. The Additional Data field 322 is similar to the Additional Data field 222 in Track 1 101, and may include the expiration date field and the service code field, with a Field Separator (FS) 316 substituted if a field is omitted. A Discretionary Data field 324 includes data like that described in connection with the Discretionary Data field 224 in Track 1 101. The one-character End Sentinel (ES) 326 indicates an end of the data structure and consists of a “?” (question mark) character. A one-character Longitude Redundancy Check (LRC) 328 is included at the end of the data structure to provide verification that Track 2 102 was accurately read by the MSR.
FIG. 4 illustrates an example data structure stored on Track 3 103. Track 3 103 may include the following data fields (in this order):
SS|FC|PAN|FS|Use and Security Data|Additional Data|ES|LRC.
The data structure of Track 3 comprises a one-character Start Sentinel (SS) 410 and a one-character End Sentinel 426, with up to 104 data characters (411) in-between. The Start Sentinel (SS) 410 and the End Sentinel 426 are “control” characters specified by the track standard 112c. The data characters 411 may also include control characters, such as characters that delimit between fields. An example of a control character included within the data sequence 411 is a Field Separator 416.
The one-character Start Sentinel (SS) 410 indicates the beginning of the data structure and consists of a “;” (semicolon) character. A two-digit Format Code (FC) 412 is numeric-only (00-to-99). A Primary Account Number (PAN) field 414 is similar to the PAN fields 214 and 314, containing up to 19 digits. The one-character Field Separator (FS) 416 consists of a “=” (equals sign) character. A Use and Security Data field 420 includes a variety of sub-fields related to currency types, payment limits, payment cycles, and card security. Sub-fields that are omitted may be replaced with a Field Separator (FS) 416.
An Additional Data field 422 may include fields indicating optional subsidiary account numbers, a digit relay marker field, a six digit crypto check field containing a validation value used to verify the integrity of Track 3 content, and various additional data. Field Separators (FS) 416 may be placed between subfields. Field Separators 416 may also be substituted for omitted sub-fields, such as when the crypto-check data field is omitted. The one-character End Sentinel (ES) 426 indicates an end of the data structure and consists of a “?” (question mark) character. A one-character Longitude Redundancy Check (LRC) 428 is included at the end of the data structure to provide verification that Track 3 103 was accurately read by the MSR.
FIG. 5 illustrates a typical structural arrangement of MSR read heads 500, including a Track 1 read head 501, a Track 2 read head 502, and a Track 3 read head 503. Double-head and triple-head arrangements are commonly used in Point-Of-Sale (POS) terminals to read credit and debit cards. In operation, the stripe 11 is inserted into a slot in a housing of the POS terminal (not illustrated) and is swiped in a direction parallel to the longitudinal axis 12 against the read heads 501/502/503 of an MSR component of the POS terminal.
The magnetic data in each track 101/102/103 is encoded using a Differential Manchester encoding format defined by the ISO/IEC-7811 standard. This format is known as “F2F” (frequency/double frequency), although it is sometimes referred to as “Aiken Biphase.” The F2F encoding format allows the serial data stored on a track to be self-clocking. As such, the signals from the read heads can be decoded without the need for a separate “clock” signal for synchronization, allowing the MSR to differentiate between individual bits encoded in the signal. The rate at which the individual bits are transmitted and received is commonly referred to as the “baud” rate (unit symbol “Bd”), with one baud equal to one bit-per-second.
In each track of a magnetic stripe card 100, bits are encoded serially on the magnetic stripe 11 using a series of magnetic flux transitions, with the magnetic domains on opposing sides of each transition having an opposite orientation of polarity relative to the other. Modeled as bar magnets, the domains alternate between south-to-north and north-to-south orientations, aligned in the direction that the card 100 will be swiped (that is, in a direction parallel to axis 12, as illustrated in FIG. 1). Each bit of data on a track has a fixed physical length on the magnetic stripe 11. Flux transitions are located at the edge of each “0” and “1” bit, and also in the center of each “1” bit.
As the magnetic stripe 11 passes by the read heads 501/502/503, the reversal of magnetic polarity at the transition from one domain to the next causes an electric current to be induced in the adjacent read head. The first read head 501 is used to read the data stored in Track 1 101, the second read head 502 is used to read the data stored in Track 2 102, and the third read head 503 is used to read the data stored in Track 3 103. Software typically installed in the POS terminal processes the data received from the MSR. Depending upon the depth of the slot and the spacing between the heads 501/502/503, MSRs can be configured to read all three tracks or particular track combinations, such as reading Track 1 101 and Track 2 102, or reading Track 1 101 and Track 3 103, or reading Track 2 102 and Track 3 103. In POS terminals configured to read only two tracks, it is unnecessary for the MSR to include the read head and associated circuitry needed to read the unread track.
As a track 101/102/103 passes a respective magnetic read head 501/502/503, the flux transitions for that channel are converted into a series of alternating positive and negative pulses in the MSR. The transitions where the “north” poles of two domains meet will produce a positive pulse in the corresponding read head. Likewise, the transitions where two “south” poles meet will produce a negative pulse in the corresponding read head.
A binary 0 is encoded using a single magnetic domain, while a binary 1 is encoded using two smaller magnetic domains. After determining which flux transitions represent the edges of a bit, ones and zeros can be differentiated by the presence or absence of a transition in the center of the bit. The polarity of the transitions is arbitrary, since only the relative space between the transitions implies a binary 1 or a binary 0. Spatially, each of the two magnetic domains used to encode a binary 1 has one-half the physical length (in the direction the card is swiped) of a magnetic domain used to encode a binary 0, such that the physical space required to represent a binary 0 and a binary 1 in a track is the same.
Although the spacing of the bits in each respective track 101/102/103 is uniform, MSRs can tolerate variation in baud rate. That tolerance is built into the hardware and software of MSRs to accommodate variations in the speed at which a stripe 11 may be swiped across the read heads 501/502/503. Different people may swipe cards 100 at different speeds, and the speed of a swipe may vary over the duration of a single swipe.
MSRs are also configured to recognize track data received in a forward direction, and to recognize track data received in a backward “reverse” direction. In the forward direction, the bits corresponding to the start sentinel 210/310/410 of a respective channel are received by the MSR before the bits corresponding to the end sentinel 210/310/410 for that channel. In the backward direction, an entirety of the bits constituting a track are received in a reversed order. This arrangement accommodates a “double swipe,” where a person pushes/pulls the stripe 11 along the read heads in one direction, and then without re-orienting the card, pulls/pushes the card back across the read heads in the reverse direction.
Disadvantageously, the data on the magnetic stripe 11 of a conventional credit or debit card is static and subject to copying and fraud. In recent years, to reduce the fraud associated with static magnetic stripe cards, electronic cards and contactless payment methods have been developed. Electronic cards and contactless methods allow the data that is provided to a POS terminal to be dynamically modified, making such approaches less susceptible to copying fraud than conventional magnetic stripe payment cards.
Electronic cards are inserted into the slot in the housing of a POS terminal and swiped along the read heads of an MSR in the same manner as a conventional magnetic stripe card 100. Electronic cards include a series of inductors arranged along a portion of at least one of the tracks 101/102/103 to simulate magnetic domains. An electronic card may include a track having both static and dynamic segments, with conventional magnetic stripe material used for the static portions, and the series of inductors providing the dynamic portions.
Since F2F requires two magnetic domains to encode a binary one, the electronic card must provide two inductors in series for each bit of simulated track data. For example, to dynamically simulate ten F2F-encoded bits, the simulated portion of the track must include twenty inductors. For each binary 0 bit, the two inductors corresponding to a bit will be configured to produce a same orientation of magnetic polarity (for example, S-N and S-N), thereby simulating a single domain. For each binary 1 bit, the two inductors corresponding to the bit will be configured to produce opposite magnetic polarities (for example, S-N and N-S), thereby simulating two domains with a signal-inducing transition in-between.
An example of a contactless payment method uses Near-Field Communications (NFC). NFC employs electromagnetic induction between a loop antenna in a handheld device and a loop antenna in a POS terminal to bidirectionally exchange information back-and-forth between the handheld device and the POS terminal. NFC operates at radio frequencies, using the globally available unlicensed radio frequency ISM band of 13.56 MHz, and transferring information at higher data rates than is possible with swiped magnetic stripe cards 100 and electronic cards. In order to be compatible with contactless methods like NFC, each POS terminals must include the needed loop antenna and receiver.
Another example of a contactless method uses an inductive loop to interact directly with the magnetic read heads (e.g., 501, 502, and 503) of the MSR. Unlike the dynamic segments of electronic cards, a single inductive loop is all that is required to simulate the entire magnetic stripe 11. Unlike the bidirectional communication used by NFC payment systems, this approach to communication with the POS terminal is limited to transmission in only one direction: from the handheld device to the POS terminal via the magnetic read heads.
An advantage of transmitting data directly to the magnetic read heads is that the POS terminal does not require any special capabilities, making the system compatible with most any POS terminals that includes a legacy MSR. For example, a POS terminal is not required to have a Near-Field Communication (NFC) receiver. Instead, a magnetic-stripe-simulating device is held in close proximity to the MSR of a POS terminal and emits a sequence of magnetic pulses from the inductive loop. While proximity between the simulating device and receiving read heads may be close, no contact is required between the simulating device and the MSR, and nothing is physically swiped by the read heads.
Instead, the simulating device generates a magnetic pulse sequence by applying a time-modulated alternating current to an inductive loop. The fluctuating magnetic field generated by the inductive loop in response to the alternating current is used to transfer F2F-encoded bits to the MSR. The data rate that is used is commensurate with a data rate that would occur if swiping a conventional magnetic stripe card across the read heads. Each reversal of the polarity of the bipolar current causes the magnetic field emitted by the inductive loop to reverse polarity The time-varying magnetic flux induces a signal in the read heads (e.g., 501, 502, and 503) similar to that caused by the transitions between magnetic domains that would occur when swiping a conventional card track 11. Typically, the inductive loop needs to be within approximately three inches (7.6 cm) of the read heads 500. The field generated by the loop dissipates rapidly beyond that point, which helps prevent the pulse sequence from being picked up by eavesdropping devices (as may not be the case with NFC transmission devices using radio frequency transmissions).
With conventional magnetic stripes, the fields generated by the magnetic domains that correspond to the data in each track/channel are narrow and confined to the reading aperture of the corresponding channel's read-head. For example, the influence of the field generated by Track 1 101 is confined to the first track read head 501, and the field generated by Track 2 102 is confined to the second track read head 502.
In comparison, the electronically-generated magnetic fields produced by the inductor(s) in magnetic stripe simulating devices may be wider than those produced by conventional magnetic stripes, resulting in the magnetic fields corresponding to a channel being picked up by the read head(s) of adjacent track(s). This problem is referred to as cross-channel “leakage.” Because the different tracks' data are formatted differently, are mutually incompatible, and/or contain different content payloads, the leakage of a specific track's magnetic fields into an adjacent track's read head can cause reading errors.
For example, if the magnetic field sequence corresponding to the higher density seven-bit characters of Track 1 101 leaks into the Track 2 read head 502, the data parsing software that was expecting the five-bit characters of Track 2 102 may indicate an error. Conversely, when Track 2 102 data leaks into Track 1 read head 501, the encoded data and the LRC may be incorrectly decoded. Because of the close proximity of the tracks in a standard card stripe 11 and because of a lack of standardization among card readers, it is difficult to prevent the cross-channel leakage.
Another example of cross-channel leakage is a conflict that can arise between Track 2 102 and Track 3 103, which both use five-bits per character, the same control characters, and include a Primary Account Number, but have different data densities and otherwise carry different payloads. Due to similarities between the Track 2 and Track 3 formats, some POS terminals may implement additional logic to check to see if the data output by the Track 2 and Track 3 decoders are equal, and return an error if “T2==T3” is true.
Cross-channel leakage may be particularly problematic for magnetic stripe transmission devices that apply a time-modulated current to a single inductive loop to interact directly with multiple magnetic read heads, since the emitted field necessarily interacts with more than one read head. While the POS terminal decoder software is designed to accommodate relatively minor track noise, such as the noise generated by scratches and small defects in the magnetic stripe 11, the decoder software can be easily overwhelmed by the substantial errors caused by cross-channel leakage. Unable to handle these exception conditions, the POS terminal will terminate the transaction.
Ideally, the decoders in the MSR are able to differentiate between channel data. One way a channel decoder may accomplish this task is by buffering the signal received from a read head, and processing the buffered data to detect an occurrence of the forward-or-backward bit patterns of a control character (e.g., the start sentinel, the end sentinel, or both). Errors can occur for a variety of reasons, such as when a decoder misidentifies a bit pattern. For example, a Track 2 decoder might detect five sequential bits that correspond to the Track 2 Start Sentinel 310, but the bits are actually part of a seven bit character in the Track 1 payload 211. Intra-channel errors can also occur at the MSR, such as clock-or-bit reconstruction errors. The decoder experiencing the errors may time-out or experience buffer overflow, missing the correct data in the stream.